Traditionally, application software for computers has followed an end-user centric model. In other words, in order to perform a particular application, an end user would purchase and install (or download and install) application software that would execute on the users computer. With the advent of the Internet, fast connections and powerful computer servers, it has been possible for various types of application software to now execute on remote Web server computers rather than on the end-user computer. The task to be performed at the end-user computer still occurs, but now there is an increase in data and information transmitted back and forth between the end-user computer and the Web server over a network connection or over the Internet.
In one example, the World Wide Web, and the Internet in general, is termed “the cloud,” applications are referred to as being performed “in the cloud” and the application that executes on the Web server is termed an “in-the-cloud service” or a “cloud service.” Client computers may now connect to a particular server computer (over a network connection or over the Internet) in order to have a service performed, and may also subscribe to such a service. Unfortunately, the increase in the use of such cloud services and the intensity of the data communications required can lead to problems. In one example, the client computer may be forced to disconnect from (or cannot connect to) a particular server computer while attempting to receive a particular service because of congestion on the computer network or because the computer server is busy. A disconnect is problematic because the network service recovery cost can be large in terms of time wasted, opportunity lost, time to reconnect, etc.
In general then, a potential problem with any cloud service is the lack of suitable bandwidth available for communication with the cloud server. In one specific example, malware scanning on a client computer makes use of a cloud service and can be affected by lack of suitable bandwidth. Historically, malware scanning identifies infected files on a client computer by comparing a hash value (or several hash values) of a suspect file with a list of hash values stored in a virus pattern file on the client computer. Pattern files can be quite large and are distributed regularly in order to provide protection against the latest threats. Currently, though, a new file reputation service decouples the pattern file from the local virus scan engine and conducts pattern file lookups over a network to a scan server in the cloud (or to a scan server located within a local or wide-area network). The pattern file is thus located on the scan server.
FIG. 1 illustrates a computing environment 10 making use of an in-the-cloud scan service 20. In general, a virus scan engine 12 (such as virus scanning API, or VSAPI) executes upon a user computer, such as the computer shown in FIGS. 9A and 9B. Also included upon the client computer is a scan controller 14 (which initializes scan mode at 1), a suspicious list 16 and a handler 18. When the scan engine receives a scan request 2 (initiated manually by the user or automatically by the computer) it calculates a CRC of a suspect file and sends a CRC query 3, 22 over the network to the cloud service 20. The CRC is compared against the pattern file located on the cloud server and the query result 24 is returned back over the network to the client computer and is processed at steps 4-7. Thus, this cloud-client file reputation (CCFR) service relies heavily upon communication over a network between the client computer and the scan service 20.
As mentioned above, there can be a very large network service recovery cost if the client computer is forced to disconnect from the service because of network congestion or because the scan server is busy (indicated by query 22 and result 24 being crossed out). The client computer typically uses the static method to communicate with the cloud service which means that the timeout value for a specific query is static, which cannot react to a real network traffic situation. In a one specific example, a CCFR BF update is affected by a lack of suitable bandwidth. A BF Update is type of pattern update event in which the client downloads the latest version from a scan server.
It can happen that many client computers perform a BF update at approximately the same time and are thus accessing the scan server over a network connection at the same time. The scan server does not consider whether the available bandwidth of the service is capable of supporting any specific client. Accordingly, if a client computer is sending a CRC query to the scan server at the same time, or may not be enough available bandwidth because of network congestion or because the scan server is busy. The client computer will then be forced to switch to an offline mode and will incur a large network service recovery cost. In the case of a client computer that is attempting to use the cloud-client file reputation service, this cost will include a reconnect time of about 3 minutes, rescanning the process, a drop in the client computer's performance, and the risk that the client computer will become infected in the meantime. Further, if the online connection is disconnected the scan engine 12 will enter off-line mode and all CRCs of scanned files will go into suspicious list 16 (even though they might be legitimate files).
Therefore, it is recognized that lack of suitable bandwidth for any of a variety of cloud services can be problematic and a solution is desired.